阿里云PB级实时数仓建设
👇点击“大数据技术团队”，一键关注
回复关键词 达摩院 可获取达摩院2022十大科技趋势报告PDF
导读：本文主要讨论了实现实时数据仓库的必要性和实时数据模型，介绍了基于AnalyticDB构建阿里云实时数据仓库解决方案的方法和优势。
摘要
如今，数据和分析对于企业来说是不可或缺的。很多企业的数据工程师、数据分析师和开发人员都希望将数据仓库迁移到云上，以提高性能和降低成本。本文讨论了实现实时数据仓库的必要性和实时数据模型，介绍了基于AnalyticDB构建阿里云实时数据仓库解决方案的方法和优势。
为什么构建数据仓库
为什么要构建数据仓库，而不是直接在OLTP数据库上运行分析查询？为了回答这个问题，我们先来看下数据仓库与 OLTP 数据库之间的差别。数据仓库主要是针对批量写入和大量数据的读取操作，而OLTP数据库是针对持续写入操作以及大量的小规模读取操作。通常，数据仓库会因较高的数据吞吐量要求而使用非规范化模型，如星型模型和雪花模型。星型架构包含多个引用大量维度表的大型事实数据表。雪花型架构是星型架构的扩展，包含更加规范化的维度表。而OLTP数据库则使用高度规范化的模型，更适合高事务吞吐量的要求，对于复杂查询的性能很难满足用户要求。
为什么构建实时数仓
传统的离线数据仓库将业务数据集中进行存储后，以固定的计算逻辑定时进行ETL和其它建模后产出报表等应用。离线数据仓库主要是构建T+1的离线数据，通过定时任务每天拉取增量数据，然后创建各个业务相关的主题维度数据，对外提供T+1的数据查询接口。计算和数据的实时性均较差，业务人员无法根据自己的即时性需要获取几分钟之前的实时数据。数据本身的价值随着时间的流逝会逐步减弱，因此数据发生后必须尽快的达到用户的手中，实时数仓的构建需求也应运而生。
实时数据仓库模型架构
实时数据仓库是用于保存从一个或多个数据源获取到的信息的中央存储库。数据通常从事务系统和其他关系数据库传输到数据仓库中，而且一般包括结构化、半结构化和非结构化的数据。这些数据将会每小时或者每分钟处理、转换和提取。科学家、业务分析师和决策者会通过BI工具、SQL客户端或者电子表格来进行数据挖掘、数据分析、报表展示或即席查询等操作。
什么是AnalyticDB
几年前阿里云就意识到实时数据仓库的必要性，2015年AnalyticDB肩负这阿里云实时数据仓库的使命上线公共云。AnalyticDB是阿里云上唯一经过核心业务和超大数据量验证的实时数据仓库，其稳定性、规模性和性能是不容置疑的。
AnalyticDB采用行列混存MPP技术，突破OLTP和传统数据仓库技术壁垒，最大优势是可以构建PB数据量下高性能和经济实用的数据仓库。全面兼容MySQL协议以及SQL:2003 语法标准，用户只需对现有业务进行少量更改，甚至不需要进行任何更改，即可把业务全部迁移到AnalyticDB上来。因此，它已成为当今企业构建数据仓库和OLAP系统的理想选择。
实时性
前面介绍说离线数据仓库计算和数据的实时性均较差，业务人员无法根据自己的即时性需要获取几分钟之前的实时数据。那么，AnalyticDB同时具有：
计算的实时性，计算在用户查询时发生，可自由变换和快速查询；
数据的实时性，数据产生插入AnalyticDB后1s-3s内就可以查询到（也可以提工单开启强一致，写入即可查）。
可以让业务人员在几秒钟甚至几百毫秒的时间内获取到包含最近几分钟内的数据计算结果，以最大的灵活度应对千变万化的业务挑战。
成本低
AnalyticDB不要求长期订阅，也不需要提前支付费用。利用此定价方法，在出现相应的需求之前，用户不必为规划和购买数据仓库容量而产生的资本费用以及由此带来的复杂性而头疼，根据购买的资源模型和数目收费。用户可以根据需求从使用按量付费的小规模数据仓库（每小时1.6元）开始，然后再逐步扩展到TB和PB级（每年每TB最低14125元）。
另外，在即将到来的AnalyticDB 3.0中用户可以使用最高与配置存储同等大小的备份存储，而不需要额外支付费用，一起期待3.0的到来吧。
动态扩展
传统的数据仓库难以扩展，当数据量增加或者需要向更多用户提供分析和报告时，用户要么选择接受较低的查询性能，要么选择在成本高昂的升级过程中投入更多的人力和物力。
AnalyticDB的扩展只需在控制台中点击几次或者使用一个API调用，用户就能在性能或容量需求发生变化时轻松地更改数据仓库中的节点的数量和类型。使用AnalyticDB，用户能够从最低180GB的单个节点开始，通过添加多个节点进行扩展，一直到1PB甚至更高容量。整个过程中用户可以正常进行在线查询和海量写入操作，业务完全无感知，不受影线。
多维复杂分析
AnalyticDB可以进行复杂的自由计算，他摒弃了传统数据库索引加速方式，默认全索引方式，用户全部精力关注在如何能够提取数据并在多个维度上敏锐地观察趋势。由于AnalyticDB已针对快速JOIN行优化，因此用他构建OLAP系统是非常合适的。
真实数据
AnalyticDB提供了单库PB级数据实时分析能力。以下是生产环境的真实数据：
阿里巴巴集团某营销应用单DB表数超过20000张
云上某企业客户单DB数据量近3PB，单日分析查询次数超过1亿
阿里巴巴集团内某单个AnalyticDB集群超过2000台节点规模
云上某业务实时写入压力高达1000w TPS
菜鸟网络某数据业务极度复杂分析场景，查询QPS 100+
为什么选择AnalyticDB
数据仓库建设无论采用哪种方式，数据收集、处理、分析和存储都不可能放在一个产品中实现，需要多个其他产品配合使用。下面列举各个过程中常用的产品，
数据收集：kafka、flume或者sync；
数据处理：hive、storm或者spark；
数据存储：hadoop、hbase，ES或者redis；
抛开性能和时效性考虑，多一个产品就多一些出现问题的几率，如果各个产品处理问题低效，直接影响数据仓库上线时间，影响企业未来。
前面我们介绍了AnalyticDB的一些功能，这些功能使AnalyticDB成为数据仓库的理想之选。除了上述特征外，还有一个重要的原因是：AnalyticDB可以集数据收集、处理、分析和存储于一体。链路简单，业务联调时间短，上线快。提高数据时效性的同时也节省了开发上线时间和运维时间，给企业带来的红利是非常明显的。为了说明如何使用AnalyticDB设计数据仓库工作流程，下面我们来看一看最常见的设计模式。
阿里云PB级实时数仓建设
数据收集
在数据收集阶段，第一点需要考虑的是用户可能具有不同类型的数据，如事务数据、日志数据、流数据和物联网 (IoT) 数据。AnalyticDB针对上述每种数据提供了数据收集解决方案。另外一点要需要考虑的是抽取频次，传统离线数据仓库会采用避开高峰期时间每天抽取一次，最快也只能做到小时级别的抽取。AnalyticDB可以做到高并发实时写入，3s内即可查。
业务数据
对于数据源为关系型数据库(如阿里云RDS)而言，可以通过数据传输服务(Data Transmission Service) 将全量和增量数据实时同步到AnalyticDB中。
业务系统也可以直接对接AnalyticDB，通过JDBC把数据直接写入数据库中。同时，AnalyticDB提供了一种更加高效和简单地insert数据到AnalyticDB的方法-ADB Client ADK。用户只需要通过接口将数据提交给ADB Client，无需关心分区聚合、连接池等问题。
日志数据
对于日志数据而言，可以通过logstash把日志数据实时同步到AnalyticDB中。
对于存储在阿里云日志服务（SLS）上的日志数据，用户可以选择把数据实时投递到AnalyticDB。
对象存储数据
对象存储OSS上的数据可以通过AnalyticDB的COPY功能快速迁移到数据库中，迁移方式比较自由，用户可以选择某个文件迁移也可以整个目录迁移。
本地数据
AnalyticDB提供了Uploader工具，可以将本地CSV和text文件数据导入到AnalyticDB中。也支持某个文件或者目录整体文件导入。
数据处理
通过数据收集过程，用户数据进入到AnalyticDB中了，已经获得可能包含有价值信息的数据。所谓数据处理就是把不需要的和不符合规范的数据进行处理，或者通过数据处理把小表组成大宽表。数据处理最好不要放在数据收集的环节进行，考虑到有时可能会查原始数据。
AnalyticDB提供多种数据处理方式：CTE，查询方式复制表(INSERT INTO......SELECT FROM)，CREATE TABLE AS（AnalyticDB 3.0支持），CREATE TABLE LIKE（AnalyticDB 3.0支持）等。如下举例说明AnalyticDB数据处理的场景：
空值处理：根据业务需要，可以将空值替换为特定的值或者直接过滤掉；
验证数据正确性：主要是把不符合业务含义的数据做一处理，比如，把一个表示数量的字段中的字符串替换为0，把一个日期字段的非日期字符串过滤掉等等；
规范数据格式：比如，把所有的日期都格式化成yyyy-MM-dd HH:mm:ss的格式等；
数据标准，统一：比如在源数据中表示男女的方式有很多种，在数据收集时候，直接根据模型中定义的值做转化，统一表示男女；
数据存储
AnalyticDB可以进行低成本数据存储，公共云上售卖的资源模型有两种：
以字母C开头的为高性能实例，适用于对性能要求高、查询并发高的业务场景。
以字母S开头的为大存储实例，适用于并发稍低，性能要求不高的（接受超过10s以上查询）的业务。还有一个最大的特点是价格低，每年每TB最低14125元。
数据分析
传统数据仓库一般使用OLTP数据库如MySQL进行加速，一般将数据处理与OLTP系统分离，使数据处理不会影响到 OLTP工作负载。但随着数据量的增长OLTP数据库会成为严重的系统瓶颈。通过AnalyticDB进行分析，当不能满足性能和存储要求时，可以随时进行横向和纵向扩展（扩容和升配），变换过程中业务完全不受影响，不用避开高峰期。